Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Paginator #1730

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from
Draft

Paginator #1730

wants to merge 6 commits into from

Conversation

anujhydrabadi
Copy link

@anujhydrabadi anujhydrabadi commented Oct 19, 2023

Description

paginator() method in PagedIterable to support starting at a particular page, and next, previous, first, last and jumping to any particular page, along with a few other supporting methods. Made in parallel to iterator() method so as to keep backward compatibility, but supports all functionality that iterator() provides.

Fixes #348
Fixes #1614
Fixes #448
Fixes #1197

Before submitting a PR:

  • Changes must not break binary backwards compatibility. If you are unclear on how to make the change you think is needed while maintaining backward compatibility, CONTRIBUTING.md for details.
  • Add JavaDocs and other comments explaining the behavior.
  • When adding or updating methods that fetch entities, add @link JavaDoc entries to the relevant documentation on https://docs.github.com/en/rest .
  • Add tests that cover any added or changed code. This generally requires capturing snapshot test data. See CONTRIBUTING.md for details.
  • Run mvn -D enable-ci clean install site locally. If this command doesn't succeed, your change will not pass CI.
  • Push your changes to a branch other than main. You will create your PR from that branch.

When creating a PR:

  • Fill in the "Description" above with clear summary of the changes. This includes:
    • If this PR fixes one or more issues, include "Fixes #" lines for each issue.
    • Provide links to relevant documentation on https://docs.github.com/en/rest where possible. If not including links, explain why not.
  • All lines of new code should be covered by tests as reported by code coverage. Any lines that are not covered must have PR comments explaining why they cannot be covered. For example, "Reaching this particular exception is hard and is not a particular common scenario."
  • Enable "Allow edits from maintainers".

@anujhydrabadi
Copy link
Author

Pending tasks:

  • Test refresh() method by changing underlying data.
  • Make a few hacky if conditions in GitHubPaginator (w.r.t. the next variable) more readable.
  • Revise and fix javadocs.
  • Capturing snapshot test data.

Question for maintainers/reviewers:

  • Should I cover every flow that calls PagedIterable with tests? Will be a huge task to have adequate tests for all of them. Currently I have picked one flow (workflow runs) where I am testing every possible case, and assuming the rest of the flows will comply, given the common nature of the APIs.
  • I have tests that make assertions on the values of the underlying data, and would fail once that data changes. Should I avoid such tests and think of more creative ways to make my assertions independent of the underlying data, or is it fine? Or is there any other way?

Review comments on the overall design/implementation/behaviour of the methods are welcome, even though it is a WIP PR for now.

@bitwiseman
Copy link
Member

Question for maintainers/reviewers:

  • Should I cover every flow that calls PagedIterable with tests? Will be a huge task to have adequate tests for all of them. Currently I have picked one flow (workflow runs) where I am testing every possible case, and assuming the rest of the flows will comply, given the common nature of the APIs.

I would assume that testing one scenario per implementation should generally be sufficient. You'll need to test search scenario separately.

  • I have tests that make assertions on the values of the underlying data, and would fail once that data changes. Should I avoid such tests and think of more creative ways to make my assertions independent of the underlying data, or is it fine? Or is there any other way?

Ideally, you should find scenarios where the underlying data doesn't change. However, if that isn't possible, once you record the test data you can mark the test as requiring custom data so that someone doesn't try to re-record it later without knowing the issues. If you go this path, be sure to add comments explaining how to update/re-record test data in future.

* @return the paged iterable
*/
public PagedIterable<T> withStartPage(int startPage) {
this.startPage = startPage;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is going to be present on this class, we'll need to pass startPage to the Iterator as well.

@bitwiseman
Copy link
Member

I'm not sure I understand why we need a separate Paginator class. It tries to smash together item iteration with page iteration. I think if people want to navigate by pages we should have a toPages(int pageSize) that returns a GitHubPageIterable or even a GitHubPageIterator (which already exists but is currently internal). Either way, this should handle iterating only over pages not their contents.

Overall I woud expect most of this to do via adding methods to existing classes, PagedIterable, PagedIterator, GitHubPageIterator, GitHubPageContentsIterable and GitHubPageContentsIterable.GitHubPageContentsIterator.

If you feel extremely strongly about this, I would even discuss pushing all the functionality of Paginator into PagedIterable and PagedIterator since it seems to be reimplementing significant portions of those classes.

@bitwiseman bitwiseman added work-abandoned There hasn't been any activity on the PR in a while. Another contributor might want to pick it up. labels Jun 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
work-abandoned There hasn't been any activity on the PR in a while. Another contributor might want to pick it up.
Projects
None yet
2 participants